Subject: Accept_*

From: "Jack Sanders (8-444-4459)" <[email-masked]>
Date: Fri, 28 May 93 10:15:30 EDT

An inconsistency has been pointed out in the CPI-C 1.2 book.  The
elaboration described below is proposed to fix the problem.

Here is the current architecture:

  The Accept calls (Accept_Conversation and Accept_Incoming) do not
specify when the call will return when there is no incoming conversation
available to satisfy the call.  There is an implication that the Accept
calls may return immediately in the CM_PROGRAM_STATE_CHECK return code
for the condition that no incoming conversation exists.  But the CPI-C
Spec does not explicitly say that either call will return immediately.
Since it is not specified (see proposed changes below), an implementation
may return immediately, wait for a system-specific (non-CPI-C) timer to
expire, or wait until an incoming conversation arrives for the program.
The CM_PROGRAM_STATE_CHECK RC is returned to the program if the
implementation returns before an incoming conversation arrives.  A
portable program must be prepared to handle that RC (by reissuing
Accept_*, for example).  And it must recognize that the implementation
may wait.  If the program can not afford to wait, it can use the
non-blocking Accept_Incoming call.

This means the current documentation is in error in Example 11 (page 60),
which states in note 3 that the Accept_Incoming will block (wait forever)
until an incoming conversation arrives.  A fix to the documentation is to
remove Example 11.

Alternatively, the following elaboration of the architecture is proposed.
It removes the current lack of definition as to when the program will get
control after an Accept call.  The proposal has two parts.

Part 1:
  Accept_Conversation is changed to state explicitly that the system
will return immediately if no incoming conversation is available.  The RC
will be state_check.  This is consistent with the original intent of the
call, which was defined when the instantiation model for a TP was that it
was started by an incoming conversation startup request.  The case of an
operator-started program was not fully explored or addressed.

Part 2:
  Accept_Incoming is changed to state explicitly that, when processing
mode is CM_BLOCKING, it will wait for an incoming conversation to arrive
to satisfy the call.  The state_check return code will no longer be
returned when an incoming conversation does not exist.  (It will still
apply to the other conditions - wrong state, no associated name).
Example 11 is valid.  The note at the bottom of Example 11 is clarified
to state that Accept_Conversation can be used to accept multiple
conversations but that state_check is returned if no incoming
conversation is available.  Of course, if the processing mode is set to
CM_NON_BLOCKING, Accept_Incoming is processed in non-blocking mode - it
returns immediately with return code CM_OPERATION_INCOMPLETE if no
conversation is available.

This proposal allows a program to poll for incoming conversations  - with
Accept_Conversation; to wait forever - with Accept_Incoming; or to use
a non-blocking accept - with Accept_Incoming.  And by removing the lack
of definition of when the system will return, it makes it easier to
write a portable program.

Any comments on the proposed architecture elaboration?

Reagrds,
Jack